Сейчас многие администраторы виртуальных инфраструктур VMware vSphere и Microsoft Hyper-V используют лидирующее на рынке решение StarWind Virtual SAN для создания отказо- и катастрофоустойчивых хранилищ под виртуальные машины. В прошлой статье мы рассматривали развертывание модуля StarWind SAN & NAS storage appliance а сегодня мы поговорим о его первоначальной настройке, которая может быть проведена через графическую консоль (Web Console) или текстовый интерфейс (Text Console)...

Летом мы писали о том, что компания VMware пустила технологическое превью своей основной платформы виртуализации для macOS - VMware Fusion 22H2 Tech Preview (тогда же было доступно и технологическое превью Player для Mac).

По итогам этого превью компания VMware на днях выпустила финальные версии VMware Fusion 13 Pro и Player для macOS.

Давайте посмотрим, что нового есть в VMware Fusion 13 Pro и и ее упрощенной версии для "проигрывания" виртуальных машин Player:

1. Поддержка гостевых ОС Windows 11 на платформах Intel и Apple Silicon

Когда-то мы писали о первом превью VMware Fusion на аппаратной платформе Apple Silicon и сложностях, которые были у команд VMware и Apple в ковидные времена? Так вот VMware доработала продукт Fusion, и теперь он работает на процессорах M1, где еще и поддерживается новая ОС Windows 11 в качестве хостовой и гостевой.

Чтобы обеспечить поддержку Windows 11, от платформы виртуализации требуется поддержка механизма Trusted Platform Module. В этом релизе для работы Virtual TPM module (vTPM) были добавлены некоторые функции. В частности, vTPM имеет реализацию механизма Fast Encryption, который предполагает шифрование только критических частей виртуальных машин и их локальных хранилищ, что намного ускоряет производительность ВМ, практически не уменьшая уровень безопасности.

Устройство vTPM может быть добавлено к любой виртуальной машине, но у нее должно быть включено Full или Fast шифрование. Делается это в разделе VM Settings > Encryption, здесь мы видим возможность выбора механики шифрования:

Для Intel-based маков вы найдете привычные вам инструменты в Windows 11 с установленными VMware Tools, которые упрощают взаимодействие с гостевой системой, такие как Drag & Drop файлов, Copy & Paste операции в консоли, общие папки (shared folders) и проброс камеры и USB-устройств хоста.

Для ARM-based маков с процессорами M1 и M2 пока только первый раунд нововведений - это функции virtual graphics and networking, сертифицированные и подписанные драйверы Windows 11 (Windows Display Driver Model версии 1.2), а также поддержка разрешения 4К и больше.

Нужно понимать, что для запуска Windows 11 на Fusion on Apple Silicon вы должны использовать ARM-дистрибутив ОС Windows, x86/x64-версия при этом не поддерживается. Для запуска таких приложений в Windows для ARM есть встроенный эмулятор - в этом случае приложения будут запущены как user-level процесс.

Если говорить о поддержке ОС, то платформа Fusion 13 сейчас работает со следующими системами:

• Microsoft Windows 11
• Microsoft Windows Server 2022
• RHEL 9
• Debian 11.x
• Ubuntu 22.04

2. Универсальный DMG пакет

Fusion 13 идет как один бинарный пакет, запакованный в DMG, который устанавливается и на Apple Silicon, и на Intel Mac, что позволяет вам на любом устростве скачивать только один дистрибутив.

3. Функции vTPM 2.0 + Fast Encryption

Чтобы обеспечить поддержку Windows 11, от платформы виртуализации требуется поддержка механизма Trusted Platform Module. В этом релизе для работы Virtual TPM module версии 2.0 (vTPM) были добавлены некоторые функции. В частности, vTPM 2.0 имеет реализацию механизма Fast Encryption, который предполагает шифрование только критических частей виртуальных машин и их локальных хранилищ, что намного ускоряет производительность ВМ, практически не уменьшая уровень безопасности.

Устройство vTPM может быть добавлено к любой виртуальной машине, но у нее должно быть включено Full или Fast шифрование. Делается это в разделе VM Settings > Encryption, здесь мы видим возможность выбора механики шифрования:

Пароль шифрования хранится в связке ключей Mac (Keychain), поэтому вам не потребуется вводить его при каждой загрузке виртуальной машины. Вы можете использовать автогенированный или собственный пароль.

4. Поддержка 3D Accelerated Graphics и библиотеки OpenGL 4.3

VMware поработала с комьюнити разных операционных систем и open-source проектов, таких как Mesa и open-vm-tools, чтобы обеспечить максимальную поддержку Linux на аппаратной платформе Apple Silicon. Постоянно выпускаются патчи для ядра, а также улучшения графического драйвера Mesa SVGA, чтобы надежно работало аппаратное 3D-ускорение на базе фреймворков OpenGL 4.3 + GLES 3.1 для виртуальных машин Linux с Mesa 22.1.1 и более поздних версий (для этого нужна версия ядра 5.19+).

Open-source драйверы устройств vmwgfx дают качественный пользовательский опыт пользователю и возможности корректного отображения различных разрешений в гостевой ОС.

Вот так работает игра Neverball в разрешении 4K на Apple Silicon с гостевой ОС Ubuntu 22.10, ускоренная движком Metal:

Также надо отметить также функцию Auto-Fit Guest Display, которая в составе Open-VM-Tools v12.0.5 позволяет выравнивать разрешение гостевой ОС, которое меняется, когда пользователь изменяет размер окна консоли. Это работает по аналогии с Debian Bookworm/Testing или Sid и Fedora 37/Rawhide. Также разрешение может быть жестко задано в меню View > Resize Virtual Machine.

На платформе Intel ОС Windows поддерживает графику DirectX 11 и Fusion продолжает поддержку устройств eGPU.

5. Поддержка VMware vSphere 8

Теперь помимо стандартных операций с хостами ESXi 8 в Fusion 13 также поддерживаются следующие:

• Подключение к хостам ESXi 8 и vCenter Server 8
• Аплоад и скачивание ВМ между ESXi и Fusion (только для Intel Mac)
• Создание новой ВМ на удаленном сервере с локального десктопа

Скачать VMware Fusion 13 и Player 13 можно по этой ссылке.

В рамках конференций Explore 2022 и Explore 2022 Europe компания VMware сделала большой анонс линейки решений Aria, которая пришла на смену семейству продуктов vRealize.

Одним из ключевых продуктов инфраструктуры Aria стало решение Aria Hub (бывший Project Ensemble). Оно предназначено для мультиоблачных инфраструктур, которые могут быть построены на базе комбинации различных частных и публичных облаков, где требуется предоставление пользователям единого и подстроенного под них интерфейса, ориентированного на приложения. Через анализ пользовательского опыта с приложениями с помощью Aria Hub и алгоритмов машинного обучения можно будет получать рекомендации по оптимизации работы с облачными приложениями, которые опираются на оптимизацию оборудования и программного обеспечения.

Надо отметить, что решение Aria Hub использует новую технологию VMware Aria Graph, которая на базе API-first подхода позволяет сотрудникам DevOps и ITOps получить доступ к графическому интерактивному консолидированному представлению приложений в различных облаках, построенному через публичные API.

Посредством VMware Aria Graph можно визуализовать карту приложений и облачной инфраструктуры на базе информации, предоставленной системами Aria Cost powered by CloudHealth, Aria Operations и Aria Automation, а также сторонними средствами для федерации облачной инфраструктуры приложений.

Решения Aria Hub и Aria Graph включены в состав пакета VMware Aria Universal Suite. В то же время, совсем недавно компания VMware по итогам конференции Explore 2022 Europe анонсировала бесплатную версию Aria Hub Free Tier, которая сейчас доступна по запросу на этой странице. Давайте посмотрим, какие возможности она дает пользователям.

Кстати, для начала работы с Aria Hub Free Tier вам не нужна облачная инфраструктура, более того, вы можете и вовсе не быть клиентом VMware, чтобы оценить возможности решения. Бесплатная версия позволит вам посмотреть на него в облаках AWS и Azure для объектов LAMP stacks или cloud native applications, работающих в ВМ EC2 или Azure, а также в кластерах Kubernetes и serverless-инсталляциях.

Итак, как только вы добавите один или два облачных аккаунта в рамках простого процесса из трех шагов, компонент Graph начнет опрашивать API облачных провайдеров, чтобы получить информацию об инвентаре, конфигурациях и затратах. После этого весь инвентарь объектов будет собран, а далее будут построены взаимосвязи между ними. Это дает базовую информацию об инфраструктуре приложений на домашней странице:

Здесь мы увидим высокоуровневый обзор инвентаря облачных приложений со ссылками на разные представления, которые доступны в Hub Free Tier, а также возможность исполнения поисковых запросов и GraphQL API.

Из бесплатных возможностей нам также доступны базовые функции VMware Aria Cost powered by CloudHealth (виджет Cost), которые показывают потенциал экономии затрат на облачные ресурсы. Также есть базовые возможности VMware Aria Automation for Secure Clouds, которые доступны в виджете Secure на домашней странице.

Если мы зайдем в Aria Automation for Secure Clouds, то увидим, что там можно визуализовать, приоритизировать и исправить ошибки конфигурации в публичных облаках и окружениях Kubernetes. В бесплатной версии можно анализировать рабочие нагрузки с помощью бенчмарка CIS и генерировать отчеты (Findings). На домашней странице доступно саммари эти отчетов. Для получения деталей можно перейти в раздел Findings:

Тут можно выбрать только интересующие вас аккаунты, провайдеров или ресурсы. Также можно фильтровать из по параметру Severity. Дополнительные функции, такие как исправление конфигураций, комплаенс средствами бенчмарков PCI, HIPPA и других, доступны по полноценной подписке на Aria Automation for Secure Clouds. Для нее доступна бесплатная пробная версия.

Главная тема Aria Hub - это предоставление информации об инфраструктуре приложений. Вы можете увидеть такие сущности как ВМ, сервисы хранилищ и БД, а также другие объекты, при этом отображаются они в контексте приложений. То есть с помощью Aria Hub Free Tier можно быстро обнаружить и смоделировать связи между приложениями. На домашней странице также доступна информация об обнаруженных и потенциально доступных приложениях:

Aria Hub обнаруживает потенциальные приложения путем группировки сущностей с похожими свойствами. Конечно же, обнаруженные группировки и связи требуют подтверждения со стороны администратора. Эти возможности доступны в Application Modeler.

В Application Modeler вы можете редактировать Potential Applications и изменять топологию приложений за счет удаления или добавления компонентов, таких как ВМ и сервисы, а также другие группы приложений. После этого полученную конфигурацию можно сохранить как Business Application. В эту конфигурацию можно вносить изменения по мере изменения модели приложения.

Общие службы (Shared services) поддерживают несколько бизнес-приложений. Например, база данных RDS может принадлежать нескольким группам и приложениям. Эти отношения можно посмотреть в представлении Search & Explore. Например, вот база данных RDS, поддерживающая два бизнес-приложения:

Эта информация полезна для траблшутинга и обслуживания инфраструктуры приложений. Также другие службы Aira Hub могут использовать информацию о бизнес-приложениях для отчетности о затратах, генерации рекомендаций по оптимизации, а также защите ИТ-ресурсов.

На главной странице также есть информация об облачном инвентаре, такая как топ-5 сервисов, растущих по ресурсам во времени. Есть и виджет Resources by Region, который показывает размещение сервисов в разных регионах:

В режиме просмотра инвентаря можно увидеть все свои облачные сервисы и отфильтровать их по признаку облака, сервиса, региона или облачного аккаунта. Можно раскрыть каждый сервис, чтобы увидеть тип сущностей и их число:

При клике на сущность вы попадаете в представление Search с готовыми запросами, которые содержат типы сущностей, которые вы выбрали. Например, вот представление для кластеров EKS:

В представлении Graph view для кластера EKS по умолчанию показываются его взаимосвязи, включая сущности Kubernetes. Вы можете "ходить" по графу, кликая на соответствующую сущность, после чего покажутся ее взаимосвязи:

Для выбранного инстанса EC2 показываются связи с узлом Kubernetes. В панели справа показаны детали сущности, такие как стоимость, метрики, свойства и тэги. Также на одном графике можно вывести одну или две метрики для быстрого анализа:

В Hub есть язык поисковых запросов, который позволяет получать списки, агрегировать результаты, показывать связи и выводить результаты в текстовом виде.

Например, вот как можно искать кластеры EKS, которые имеют публичный доступ, а далее посчитать число таких кластеров по регионам AWS. В query builder просто создаем условия с указанием имен свойств и возможных значений:

Результат будет вот таким:

По клику на Resource Count откроется представление Graph, которое можно исследовать:

Во время вашей сессии сохраняются последние поисковые запросы, которые можно использовать повторно:

Это краткий обзор функций VMware Aria Hub Free Tier, далее вы можете поизучать данное решение самостоятельно (напомним, что бесплатная версия доступна по ссылке). Если лень самому разбираться, то есть вот такое интерактивное кликабельно демо.

Ну и вот несколько полезных ссылок на статьи и ресурсы об Aria Hub Free Tier:

• Announcing VMware Aria Hub Free Tier
• Introducing VMware Aria
• Introduction of VMware Aria at VMware Explore US
• VMware Aria Graph: API First Approach
• VMware Aria Hub Hands-on-Labs (HOL) VMware Explore Barcelona 2022
• VMware Aria Universal Suite

На сайте проекта VMware Labs вышло обновление утилиты Control My Update 2.1.3. Напомним, что это средство позволяет контролировать и управлять всеми обновлениями, предоставляемыми через Windows Update. В прошлый раз мы писали об этой утилите вот тут.

С помощью Control My Update можно создавать полностью поддерживаемые со стороны Windows Update конфигурации и использовать саму утилиту для их установки и мониторинга. CMU состоит из двух отдельных компонентов:

• Custom Profile Generator - это графическая PowerShell-утилита, которая дает GUI для конфигурации профилей Windows Update с наиболее актуальными поддерживаемыми настройками (20H2 и более поздние). Также можно создавать Delivery Optimization Profiles и конфигурации самой утилиты Control My Update.
• Control My Update - это надстройка над Windows Update для накатывания патчей и формирования отчетов. Вы можете выбрать источник обновлений - WSUS или Microsoft Update, определить окна обслуживания для установок обновлений и загрузить все необходимые апдейты перед установкой (что уменьшает время для нескольких систем). После этого можно накатить обновления и emergency-патчи, создавать кастомные нотификации и исключать отдельные KB из потока установки обновлений.

Посмотрим, что нового появилось в Control My Update версии 2.1.3 (а также 2.1.1 и 2.1.2):

• Добавлена поддержка Windows 10 и 11 22H2
• Добавлена очень полезная функция Update Rollback
• Добавлена опция перезагрузки в случае, если пользователь не залогинен в систему
• Добавлена функция назначения сенсора при адплоаде и назначении сенсоров
• Новая опция по включению/отключению тестирования соединения. Также тест соединения запускается по тому же расписанию, что и Windows Update search
• Поправлена проблема с нотификацией, когда устройство использует окно обслуживания
• Пофикшен баг, который возникает при установке одиночного обновления

Скачать Control My Update версии 2.1.3 можно по этой ссылке.

На днях компания VMware объявила о доступности обновленной версии решения Cloud Provider Lifecycle Manager 1.4 (VCPLCM). Напомним, что этот продукт предназначен для автоматизации рутинных операций жизненного цикла продуктов, для которых можно разрабатывать свои сценарии развертывания, обслуживания и списания систем, что позволяет сотрудникам сервис-провайдеров (VCPP) сосредоточиться на более высокоуровневых операциях. В прошлой версии этого средства появился графический интерфейс, о чем мы писали вот тут.

Основные нововведения Cloud Provider Lifecycle Manager 1.4 сосредоточены в трех областях:

1. Упрощенные операции

Теперь в разделе Environments есть кнопка Register Environment, с помощью которой можно просто импортировать продукт и окружение, после чего он добавится в управляемые системы.

Также в графическом интерфейсе доступны новые Day-2 операции, чтобы выровнять функции API и GUI. Теперь вы можете управлять следующими вещами:

• Апгрейд продуктов
• Управление сертификатами
• Управление узлами

Функция Discover была добавлена для отслеживания изменений и модификаций, которые были сделаны в развернутом продукте, и синхронизации их с репозиторием Lifecycle Manager Repository.

Теперь вы можете обнаружить изменения в развернутом продукте в окружении и в зарегистрированном датацентре. Более подробно об этом рассказано в документации.

2. Уменьшенное время исполнения задач

Наконец-то появилась возможность одновременного исполнения задач - теперь сотрудникам сервис-провайдеров не нужно ждать завершения предыдущей задачи, чтобы стартовать следующую. Это особенно удобно, когда вы делаете апгрейд сразу нескольких окружений. Кроме того, пользователи могут запросить постановку задачи в очередь, и если сейчас не свободного слота для исполнения - задача будет выполнена позже.

Ну и появилась возможность детализированного просмотра продуктов и компонентов. Это улучшение позволяет облачным провайдерам проводить ревью исполняемых продуктов в их окружениях, а также развернутых и зарегистрированных спецификаций продуктов. Для этого надо нажать кнопку Open в карточке продукта:

3. Улучшенный траблшутинг

В VCPLCM 1.4 вы можете получать логи и сообщения об ошибках через GUI или API, просто залогинясь на хост VCPLCM по SSH. Теперь отдельные лог-файлы создаются для каждой задачи с уникальным ID, чтобы упростить решение проблем.

Также появилась опция генерации бандла поддержки (support bundle), чтобы получить все необходимые конфигурационные файлы в архиве через API или GUI.

Кроме того, был упрощен процесс проверки и развертывания пакетов Interop Bundles. Теперь вы можете проверить доступность последнего interop bundle и обновить его через GUI. В разделе Administration доступны опции Check for Interop Bundle Update и Update Interop Bundle:

Также теперь при логине в GUI появляется баннер, который периодически проверяет доступность версий interop bundle и предлагает обновиться, чтобы ваш хост VCPLCM был всегда последней версии. Помните, что для работы функций VCPLCM нужен доступ к VMware Customer Connect.

Ну и появилась автоматизация структуры каталогов репозитория. При первоначальной загрузке начинается автоматическое создание репозиториев под поддерживаемые директории продуктов в этом релизе, поэтому теперь нет необходимости создавать их вручную.

Загрузить VMware Cloud Provider Lifecycle Manager 1.4 можно по этой ссылке. Документация доступна тут.

На прошедшей в конце лета конференции Explore 2022 компания VMware представила множество новых продуктов и технологий. Некоторые из них можно назвать "VMware Projects" - это те анонсированные продукты, которые находятся в ранней стадии разработки и будут представлены в будущем как часть существующих платформ или как отдельные решения. О них мы сегодня и поговорим.

В начале года мы рассказывали о ситуации вокруг продукта VMware vCenter Converter, предназначенного для миграции физических и виртуальных серверов в онпремизную и облачную среду VMware vSphere. На тот момент Converter был убран из списка доступных загрузок из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивался - последний релиз VMware vCenter Conterter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет до этого. Поддержка этого продукта закончилась в декабре 2019, а последний раз до этого о нем мы упоминали вот тут.

Выглядел он тогда так:

И вот на днях компания VMware объявила о выпуске новой версии продукта VMware vCenter Converter Standalone 6.3.0, который поддерживает миграцию на платформу VMware vSphere 7, включая ее пакеты обновлений. К сожалению, поддержки vSphere 8 мы пока не получили (хотя технически перевести туда виртуальную машину с помощью Converter не очень-то сложно).

Продукт был в состоянии беты с сентября этого года, и вот так он теперь выглядит:

Давайте посмотрим на новые возможности Converter 6.3.0:

1. Обновился список поддерживаемых физических платформ для установки Converter

Теперь для целей P2V (Physical-to-Virtual) и V2V (Virtual-to-Virtual) миграции вы можете установить конвертер на следующие десктопные и серверные системы:

• Windows Server 2012 (64-bit)
• Windows 8.1 (32-bit and 64-bit)
• Windows Server 2012 R2 (64-bit)
• Windows 10 (32-bit and 64-bit)
• Windows Server 2016 (64-bit)
• Windows Server 2019 (64-bit)
• Windows 11 (64-bit)
• Windows Server 2022 (64-bit)

2. Обновился список поддерживаемых гостевых ОС для конвертации

Теперь с помощью vCenter Converter вы можете перенести в виртуальную среду vSphere виртуальные и физические машины под управлением следующих операционных систем:

• Windows Server 2012 (64-bit)
• Windows 8.1 (32-bit and 64-bit)
• Windows Server 2012 R2 (64-bit)
• Windows 10 (32-bit and 64-bit)
• Windows Server 2016 (64-bit)
• Windows Server 2019 (64-bit)
• Windows 11 (64-bit)
• Windows Server 2022 (64-bit)
• CentOS 6.x (32-bit and 64-bit)
• Red Hat Enterprise Linux 6.x (32-bit and 64-bit)
• Red Hat Enterprise Linux 7.x (64-bit)
• Ubuntu 14.04 LTS (32-bit and 64-bit)
• Ubuntu 16.04 LTS (32-bit and 64-bit)

Внимание! При переносе следующих файловых систем машин Linux их файловые системы будут сохранены:

• ext2
• ext3
• ext4
• reiserfs
• vfat
• xfs

Все остальные ФС будут сконвертированы при миграции в ext3 или ext4 на целевой виртуальной машине.

3. Обновился список поддерживаемых платформ для V2V-миграции

Теперь можно переносить в среду vSphere виртуальные машины под управлением гипервизора Hyper-V на следующих платформах Microsoft:

• Windows Server 2012 (64-bit)
• Windows Server 2012 R2 (64-bit)
• Windows 10 (32-bit and 64-bit)
• Windows Server 2016 (64-bit)
• Windows Server 2019 (64-bit)
• Windows 11 (64-bit)
• Windows Server 2022 (64-bit)

4. Поддержка целевых платформ VMware

Теперь виртуальные и физические машины можно перенести на следующие платформы VMware:

• VMware vSphere 6.5 (Update 3)
• VMware vSphere 6.7 (Update 3)
• VMware vSphere 7.0
• VMware vSphere 7.0 (Update 1)
• VMware vSphere 7.0 (Update 2)
• VMware vSphere 7.0 (Update 3)
• VMware Workstation 16.x
• VMware Fusion 12.x

5. Программа Customer Experience Improvement Program

Теперь продукт vCenter Converter участвует в программе CEIP, что подразумевает сбор информации о пользовательских окружениях в целях улучшения их опыта. В рамках CEIP собирается следующая информация о виртуальной среде:

• Configuration Data – как и что у вас настроено в плане продуктов и сервисов VMware.
• Feature Usage Data - как именно вы используете возможности продуктов и сервисов.
• Performance Data - производительность различных объектов виртуальной инфраструктуры в виде метрик и численных значений (отклик интерфейса, детали об API-вызовах и прочее).

Если в рамках вашего плана поддержки вы используете Enhanced Support для CEIP, то на серверы VMware для анализа отправляются еще и продуктовые логи (Product Logs). Документация по CIEP доступна здесь.

Несколько важных моментов при использовании vCenter Converter:

• Converter Standalone 6.3.0 не поддерживает версии Virtual Hardware выше 11. У целевых машин возможности будут ограничены именно этой версией виртуального железа. Дальнейший апгрейд вам надо делать самостоятельно.
• Пока поддерживается только размер секторов 512B (512e и 512n). Нативные 4K-диски (4Kn) не поддерживаются.
• Converter Standalone 6.3 поддерживает только те ОС RHEL 6.x и CentOS 6.x, которые используют SSH-ключи с аутентификацией RSA SHA1. Новые алгоритмы, такие как RSA SHA2 или ECDSA, не поддерживаются.

Скачать VMware vCenter Converter Standalone 6.3.0 можно по этой ссылке. Release Notes доступны тут.

Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.

Начать можно с виртуальной тестовой лаборатории, то есть инсталляции в рамках одного сервера или рабочей станции, где сервисы ESXi, vCenter и vSAN поднимаются в виртуальных машинах.

Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.

Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).

Итак для этого вам понадобятся:

• Действующий vCenter Server не ниже седьмой версии
• Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
• Виртуальный модуль vCenter Server Appliance 8.0 Build 20519528 OVA
• Виртуальный модуль Nested ESXi 8.0 IA OVA

Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.

Пример исполнения сценария показан ниже:

В итоге процесс будет выполняться пошагово до его завершения с информацией о каждом шаге:

Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:

Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.

Компания VMware на днях сделала доступной для скачивания обновленную версию платформы виртуализации VMware vSphere 8 и решение для организации отказоустойчивых хранилищ VMware vSAN 8. Одновременно с этим VMware решила обновить и свою платформу VMware Cloud Foundation (VCF) до версии 4.5. Напомним, что VCF - это главное программное комплексное инфраструктурное решение VMware, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О прошлой версии этой платформы мы писали вот тут.

Давайте посмотрим, что нового появилось в VMware Cloud Foundation 4.5:

• Поддержка VCF+. Теперь эту подписку на облачные сервисы можно использовать в рамках составляющих - vSphere+ и vSAN+. Доступность VCF+ пока не анонсирована.
• Теперь можно добавлять кластеры, а также добавлять/удалять хосты и вводить/выводить их из эксплуатации в параллельном режиме.
• Предпроверки апгрейдов теперь могут проверять лицензии и пароль к кластеру NSX-T edge, а также разрешения на файлы, пароли и ротацию сертификатов для неуспешно завершенных задач. Раздражающие проверки vSAN health checks можно отключить.
• Пользователи теперь могут переименовывать кластеры и применять тэги к объектам.
• SDDC Manager теперь предоставляет интерфейс на базе мастеров, который делает процедуру конфигурации окружения VCF более простой.
• Для архитектуры HCI Mesh на базе vSAN ReadyNodes в кластер можно смонтировать удаленный датастор vSAN, который был настроен в другом кластере.
• Рабочие процессы VxRaildomain manager теперь соответствуют таковым для vSAN ReadyNodes. Также были улучшен LCM при выполнении повторных попыток операций.
• Переработан интерфейс, в том числе, чтобы слабовидящим пользователям работать было удобнее.
• Поддержка миграций в режиме Mixed Mode, а также новых топологий миграции с VCF 3 на четвертую версию.

VMware Cloud Foundation 4.5 включает в себя следующие версии компонентов (Bill of Materials):

• Cloud Builder VM: 4.5
• SDDC Manager: 4.5
• VMware vCenter Appliance: 7.0 Update 3h
• VMware ESXi и VMware vSAN: 7.0 Update 3g
• VMware Virtual SAN Witness Appliance: 7.0 Update 3c
• VMware NSX-T: 3.2.1.2
• VMware vRealize Suite Lifecycle Manager: 8.8.2

За счет интеграции с VMware NSX-T 3.2.1.2 архитектура VCF получила следующие возможности:

Вкратце, тут появились такие нововведения:

• Улучшения NSX Federation - поддерживаются функции репликации тэгов ВМ, поэтому они сохраняют политики безопасности в случае события аварийного восстановления. Также были улучшены функции мониторинга каналов между Global Managers и Local Managers.
• Доработки Gateway Security и Distributed Firewall - улучшения были сделаны для L7 App ID, Malware Detection и Sandboxing, фильтрации URL и сетевого экрана на базе User-ID. Кроме того, появились функции TLS inspection (в режиме Tech Preview), а также поддержка Intrusion Detection and Prevention Service (IDS/IPS).
• Теперь можно определять сетевые политики и политики безопасности Antrea для контейнеров из интерфейса NSX-T Manager. Объекты, которые видит инвентарь NSX-T включают в себя: pods, пространства имен и сервисы. Также их можно увидеть в политиках распределенного сетевого экрана (Distributed Firewall).
• NSX Migration Coordinator был улучшен в целях поддержки определяемых пользователем топологий NSX. Теперь поддерживаются большие инсталляции, инфраструктура VMware Integrated OpenStack (VIO), фиксированные топологии с OSPF, функции Guest Introspection и конфигурации identity-based firewall (IDFW/RDSH).

Более подробно о VMware Cloud Foundation 4.5 можно прочитать в Release Notes. Скачать составляющие платформы можно по этой ссылке.

Вчера мы писали о том, что решение VMware vSphere 8 стало доступным для загрузки (Initial Availability). Анонсированная на конференции Explore 2022 платформа приобрела не только новые функции клиента vSphere Client, предназначенного для управления инфраструктурой на базе vCenter, но и получила новую версию хостового клиента для отдельных серверов ESXi Host Client 2, который удобно использовать, когда vCenter недоступен.

Напомним, что в прошлый раз о этом клиенте мы писали вот тут, тогда VMware планировала выпустить его второе поколение в конце 2021 года. Теперь Host Client 2 поддерживает не только управление инфраструктурой vSphere 8, но и серверы виртуализации vSphere 7.0 Update 6 (обновление пока не вышло).

Итак, что же нового в VMware ESXi Host Client 2:

1. Обновленная иконка приложения

Самое главное:)

2. Новый дизайн интерфейса на базе фреймворка Clarity

Многие из вас в курсе, что VMware перевела почти все свои интерфейсы на собственный open source фреймворк Clarity, и хостовый клиент стал очередным продуктом, который также был на него переведен. Рабочие процессы теперь выглядят более опрятно, а шаги мастеров - более организованно:

Браузер датасторов теперь дает больше информативности, а сами надписи и информационные лейблы стали более читаемыми. Файлы теперь можно загружать в параллельном режиме в фоне, а колонки позволяют обеспечивать видимость глубокой структуры каталогов:

3. Улучшенные иконки

Теперь в качестве визуальных элементов используется более 100 иконок, которые соответствуют таковым из конвенционального vSphere Client. Все иконки стали монохромными, чтобы не нагружать интерфейс и глаза.

Вот так выглядят портлеты свойств:

А вот так - действий:

4. Специальные возможности

Теперь для слабовидящих людей есть приятные улучшения. Элементы попадают в обводку:

Для полей ввода есть выделение (можно переключаться между ними по Tab или Shift+Tab), а на вкладках четко видны активные элементы:

5. Выбор светлой или темной темы

Тему можно выбрать в разделе Help > About > UI Preferences Theme:

На выбор есть 3 темы. Стандартная - это светлые цвета и мягкий контраст:

Классическая - для привыкших к стандартному белому фону:

И темная - для чувствительных к свету и любителей работать по ночам:

Но вообще по кнопке Customize можно настроить различные цвета для визуальных групп:

6. Кастомизабельный стартовый экран

В файле /etc/vmware/welcome можно редактировать иконку и приветственное сообщение, которые могут быть индивидуальными для каждой компании:

Таблица поддерживаемых браузеров сейчас выглядит так:

Клиент ESXi Host Client 2 в обновленной платформе VMware vSphere 8 доступен администраторам по ссылке в браузере:

https://host-name/ui

По итогам прошедшей конференции Explore 2022 компания VMware сделала доступной финальную версию решения Tanzu Application Service 3.0, представляющего собой среду исполнения для микросервисных приложений под управлением Cloud Foundry в облаках различного типа.

Давайте посмотрим, что нового появилось в VMware Tanzu Application Service 3.0:

Функции для разработчиков

• Улучшения поиска Apps Manager - разработчики и операторы теперь могут искать отдельных пользователей в Apps Manager, что удобно в больших организационных структурах.

• Расшаренные маршруты между пространствами (spaces) - теперь их можно создавать видимыми на всех уровнях Cloud Foundry Spaces. Можно передеплоить приложение и привязать его к общему маршруту для миграции приложения между пространствами.
• Поддержка архитектуры Apple M1 для интерфейса командной строки - теперь в Cloud Foundry CLI нативно поддерживается M1.
• Функции Step-up autoscaling в Apps Manager - эти возможности были доступны в Cloud Foundry CLI, а теперь переехали и в Apps Manager, что логично - так как управлять масштабируемостью инстансов нужно наглядно.
• Появилась документация о лучших практиках в Autoscaler.
• Поддержка Integrated Windows Authentication (IWA) для .NET Core buildpack.
• Поддержка cloudfoundry/cflinuxfs4 в бета-режиме - теперь разработчики могут развертывать приложения, используя файловую систему cflinuxfs4 с Java, Node и .Net Core. Это позволяет переехать со стека cflinuxfs3.
• Механика Fair CPU - если эта функция включена, то слишком требовательные приложения не смогут забирать циклы CPU у других приложений. Работает это вот так:

Функции для операторов

• Новый формат версий - теперь он представлен в виде Major.Minor.Patch+Metadata, чтобы сообщество понимало уровень произошедших изменений в каждом релизе. Более подробно об этом написано тут.
• Обновления долговременной поддержки (long-term support, LTS) - теперь это называется long-term support track (LTST). Обновления в рамках LTST будут проводиться где-то раз в год, это позволит получать новые фичи быстрее, а не ждать 2 года, как это было с прошлой механикой релизов. Подробнее здесь.
• Более гибкие функции работы с логами - теперь операторы могут настроить квоты логов на уровне организаций и пространств, а также лимиты по объемам логов, чтобы избежать проблем с переполнением этих файлов, а также дать оператору инструменты по приоритизации записей приложений в логах в зависимости от критичности.
• Tanzu Application Service теперь поддерживает объекты stemcells на базе Jammy Jellyfish или Ubuntu 22.04 LTS. Это позволяет операторам безопасно развертывать последние версии ОС.
• Улучшенная аллокация IP для объектов Diego cells - теперь оператор может уменьшить потребление IP-аллокаций этими объектами.
• Переработка опенсорсного механизма User Account and Authentication - теперь он лучше интегрирован с Cloud Foundry.
• Логи событий Capture Cloud Controller теперь можно отправлять через Syslog.
• Возможность отключить метрики GoRouter, чтобы не создавать нагрузку на подсистему backend logging.
• Внутренняя платформа баз данных на базе MySQL была обновлена до версии PXC 8.0.
• Убран BOSH System Metrics Forwarder - устаревший компонент был убран из Tanzu Application Service 3.0, поэтому теперь не будет дубликатов метрик, а само их количество уменьшится до приемлемого объема. Для получения расширенного набора метрик можно использовать System Metrics Scraper.

Обновления Tanzu Application Service 3.0 for Windows

• Убран Event Log Forwarder – теперь в Tanzu Application Service 3.0 for Windows его заменили на новый релиз windows-syslog, который существенно улучшает безопасность системы, а также выравнивает функциональность с Linux-версией.
• Автоматический перезапуск BOSH-агента для Windows cells - теперь после рестарта виртуальной машины агент BOSH также автоматически перезапускается. 

Расширения платформы

• Доступен Application Service Adapter для VMware Tanzu Application Platform – был разработан слой совместимости Cloud Foundry с решением Tanzu Application Platform (он называется Application Service Adapter). Он был доступен как бета-версия еще с января этого года, а до конца 2022 должен состояться его финальный релиз. Это позволит использовать единый набор базовых инструментов разработчикам Cloud Foundry и Kubernetes на базе Tanzu Application Platform.

Загрузить компоненты среды исполнения VMware Tanzu Application Service 3.0 можно по этой ссылке.

На сайте проекта VMware Labs появилась еще одна интересная утилита Horizon Network Label Assignment Tool. Она предназначена для решения проблемы исчерпания IP-адресов в сетях, назначаемых виртуальным машинам пулов VMware Horizon.

Виртуальные десктопы в пулах Horizon Automated Linked Clone или Full Clone по умолчанию наследуют сетевой интерфейс (NIC) с сетью (network label) от родительской виртуальной машины или шаблона. Это означает, что если в этой сети кончаются IP-адреса, то там уже нельзя развернуть новые машины и администратору нужно как-то расширить диапазон адресов в сети для пула или добавить новую сеть, назначив ее членам пула.

Horizon Network Label Assignment Tool помогает администратору развертывать большие пулы десктопов с одной родительской виртуальной машиной (Parent Virtual Machine) или шаблоном (Template) за счет установки сети из нескольких доступных, которые настроены на хосте ESXi нужного кластера. Утилита также дает возможность сбросить и просмотреть установленные ранее настройки network label в табличном формате.

Network Label Assignment Tool дает возможность изменять сети для следующих пулов и ферм виртуальных ПК:

• Пулы Linked Clones Automated Desktop
• Пулы Full Clone Automated Desktop
• Фермы RDS (Linked Clones)   

Вот какие настройки доступны в интерфейсе утилиты:

• Задание настроек Network Label для пулов и ферм
• Сброс этих настроек до изначальной сети родительской ВМ или шаблона
• Просмотр существующих настроек для пулов и ферм

Утилита Horizon Network Label Assignment Tool построена на базе Windows PowerShell и имеет следующие требования:

• Windows 10 x64 / Windows Server 2016 или более поздние
• PowerShell версии 5.1
• Модуль VMware PowerCLI
• Horizon 7.13.x / Horizon 8 2006 (поддержка пулов и ферм) Horizon 8 2012 (поддержка только пулов) или более поздние

Скачать Horizon Network Label Assignment Tool можно по этой ссылке, документация доступна тут.

В конце лета этого года компания VMware провела конференцию Explore 2022, где представила новую версию решения для создания отказоустойчивых хранилищ VMware vSAN 8. Главным нововведением обновленной платформы стала архитектура Express Storage Architecture (ESA), которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения. Сегодня мы посмотрим, какие улучшения механизма работы снапшотов появились в vSAN, работающем в ESA-варианте.

Еще много лет назад мы писали о том, что снапшоты - это зло, и использовать их нужно с большой осторожностью и при большой необходимости. Например, перед обновлением виртуального аппаратного обеспечения, ОС или критичных приложений можно сделать снапшот, проверить что все в порядке после обновления, а затем удалить его.

Снапшоты, создаваемые для специфических целей администраторов, часто разрастаются в разных ветках, что в итоге приводит к падению производительности виртуальной машины и операционным сложностям при консолидации (например, недостаток места). При этом снапшоты - это вещь нужная для таких процессов, как резервное копирование и автоматизированные рабочие процессы Continuous Integration/Continuous Delivery (CI/CD), Copy Data Management (CDM), а также управление виртуальными ПК VMware Horizon.

Часто в большой инфраструктуре VMware vSphere можно обязательно найти вот такую машину, которая "почему-то тормозит":

Традиционно снапшоты в VMware vSphere строились на базе технологии redo-log (дельта диск отличий от основного VMDK), которая имеет ограничения по масштабируемости и производительности. Снапшоты типа VMFSsparse использовались по умолчанию в файловой системе VMFS5 для дисков менее 2 ТБ и для всех дисков на системах до VMFS5.

VMFSsparse работает поверх VMFS как redo-log, который создается пустым, как только для ВМ создается снапшот, и растет до размера родительского VMDK-диска, накапливая данные. Начиная с VMFS5, для дисков более 2 ТБ и для всех дисков VMFS6 был добавлен формат снапшота VMFS SEsparse. Это эволюционное изменение снапшотов, которое давало улучшения в плане склеивания снапшотов и в отношении их больших цепочек, где ранее происходила потеря производительности.

Также для SEsparse снапшотов было сделано множество улучшений в новых версиях vSphere, например, при чтении данных для машин со снапшотами была существенно увеличена производительность: чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение:

Также были сделаны некоторые оптимизации "подмораживания" (stun) при различного рода операциях со снапшотами, а также специфические технологии, такие как Mirror driver, но концептуально суть снапшотов не поменялась. Поэтому VMware продолжала давать рекомендации не хранить их более 48 часов и не создавать длинных цепочек снапшотов, особенно для критичных нагрузок.

Архитектура снапшотов в vSAN базируется на традиционных redo-log снапшотах, которые были доработаны - так появился формат vsanSparse (начиная с vSAN 6). Он использует механизм redirect-on-write и снижает некоторые технические ограничения снапшотов за счет кэширования, но проблемы подмораживания и долгого времени удаления снапшотов остаются.

В новой версии vSAN 8 при использовании архитектуры ESA, снапшоты используются совершенно другим образом, нежели в прошлых версиях платформы. Вместо использования традиционной цепочки базового и дельта-дисков, механизм снапшотов использует lookup table, применяя структуры B-Tree.

Файловая система log structured file system в vSAN ESA позволяет новым операциям записи помещаться в новые сегменты хранилища с их указателями метаданных, интеллектуально размещая их в соответствии с принадлежностью к снапшотам. В этом случае время удаления снапшота снижается более чем в 100 раз по сравнению с прошлыми версиями платформы vSAN.

Также новая архитектура снапшотов снижает и накладные расходы на вычисления и перемещения данных, которые происходят при удалении снапшотов (а это были одни из самых нагружающих инфраструктуру операций). По-сути, когда в vSAN 8 удаляется снапшот, происходит лишь удаление метаданных, а физического перемещения блоков не происходит.

Мало того, пользователь получает подтверждение удаления снапшота сразу же, а удаление данных и метаданных происходит позже, в асинхронном режиме. Новая архитектура снапшотов ESA позволяет использовать практически неограниченное количество снапшотов - однако текущие параметры платформы vSphere ограничивают число снапшотов числом 32 на один объект.

Как знают администраторы VMware vSphere, решения для резервного копирования используют снапшоты через vSphere Storage API (также называемые VADP) для передачи резервных копий на хранилища. Новая функциональность vSAN ESA автоматически заменит старый механизм снапшотов, а пользователи увидят реальный прирост производительности при консолидации снапшотов, а также при работе продуктов VMware SRM и vSphere Replication в кластерах ESA.

На конференции Explore 2022 компания VMware объявила о выпуске новой версии платформы VMware vSphere 8, о возможностях которой мы уже писали. Сегодня мы посмотрим, что нового появилось в механизме работы томов vVols, которые позволяют более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.

Сегодня мы поговорим о нововведениях, которые появились в технологии vVols для восьмой версии платформы.

1. Поддержка технологии NVMe-oF

Это большое нововведение означает поддержку томами vVols на платформе vSphere 8 технологии NVMe-oF. В новой спецификации vVols появились определения vSphere API для механики работы с хранилищами VASA (vSphere Storage APIs for Storage Awareness) 4.0.

Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.

NVMe-oF имеет преимущество в виде меньших задержек (latency) над традиционным интерфейсом SCSI. Эта технология изначально предназначена для флэш-памяти и позволяет подключать all-flash NVMe дисковые массивы с очень высокой производительностью.

В рамках технологии NVMe-oF vVols каждый объект vVol становится пространством имен NVMe Namespace. Эти пространства имен группируются в ANA group (Asymmetrical Namespace Access). Многие команды проходят как In-Band для более эффективной коммуникации между хостами ESXi и дисковыми массивами.

Также упростилась настройка томов, в том числе NVMe с технологией vVols. При развертывании NVMe в vCenter, когда зарегистрирован VASA-провайдер, оставшаяся установка происходит в фоновом режиме, а обнаружение NVMe-контроллеров происходит автоматически. Как только создается датастор, объекты vPE (virtual Protocol Endpoints) и само соединение подхватываются и обрабатываются автоматически.

2. Дополнительные улучшения vVols NVMe-oF

Они включают в себя следующее:

• Поддержка до 256 пространств имен и 2000 путей
• Расширенная поддержка механизма резерваций для устройств NVMe - это позволит поддерживать функцию Clustered VMDK для кластеризованных приложений, таких как Microsoft WSFC на базе хранилищ NVMe-oF 
• Функции автообнаружения в механизме NVMe Discovery Services для ESXi при использовании NVMe-TCP для обнаружения контроллеров NVMe

3. Прочие улучшения

• Улучшение VM swap - уменьшенное время при включении и выключении для обеспечения лучшего быстродействия vMotion
• Улучшенная производительность компонента config-vVol - убраны задержки при обращения виртуальных машин к платформе ESXi

На прошедшей в конце лета конференции Explore 2022 компания VMware рассказала о большом количестве новых технологий, а портфолио продуктов сильно расширилось.

Недавно мы писали о продукте VMware Aria Operations for Networks 6.8, который предназначен для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре. Также мы рассказывали о новом семействе продуктов VMware Aria (бывшая линейка vRealize Cloud Management), под зонтиком которого VMware собрала все средства для управления приложениями и виртуальными датацентрами в онпремизной и облачной инфраструктуре.

Сегодня мы поговорим о решении VMware Aria Operations 8.10 - платформе, предназначенной для комплексного управления и мониторинга виртуальной облачной инфраструктуры в различных аспектах, которая пришла на смену решению VMware vRealize Operations.

Ранее возможность Management Pack Builder, позволяющая создавать менеджмент-паки для Operations, была анонсирована в качестве бета-программы. Это no-code решение, с помощью которого экосистема таких пакетов для vROPs расширяется с сотен продуктов до тысяч - каждый администратор может теперь создать свое расширение.

Можно соединиться через Rest API с использованием HTTP или AWS дата сорса, делать API-вызовы, создавать объекты и строить взаимосвязь с другими объектами Aria Operations.

Эта функциональность будет доступна для изданий Aria Operations Advanced и Enterprise.

2. Выполнение простых действий в публичном облаке

Теперь в интерфейсе Operations 8.10 можно автоматически инициировать простые операции для определенного инстанса AWS, Microsoft Azure или GCP CE. Это дает возможность администраторам возможность не ходить по разным консолям для выполнения часто необходимых действий - старт, остановка или перезагрузка виртуальных машин.

3. Обнаружение приложений на базе правил

Теперь можно обнаруживать множество видов приложений, которые работают в различных сферах ИТ-инфраструктуры компании, а также просматривать ассоциированные ресурсы на базе правил, определенных пользователем. Обнаруживать приложения можно на основе тэгов, свойств и имен объектов.

4. Улучшенное планирование емкостей

Теперь администраторам доступны расширенные средства планирования емкостей (capacity planning) для будущих новых проектов с использованием функций анализа "что если" (what-if analysis). Результаты можно просматривать на базе вашей модели выделения ресурсов и даже определять рабочие часы для корректного определения объемов рабочих нагрузок.

5. Алерты

Напомним, что в vROPs был анонсирован новый механизм алертинга, называющийся условия (Conditions). В отличие от симптомов (Symptoms), которые могут быть привязаны к нескольким алертам, условия привязываются к одному определению алерта.

Например, у вас есть три команды, отвечающие за три кластера A, B и C, и они должны быть оповещены о событии отключения хоста. В этом случае вы создаете симптом, который вызывает алерт в случае отключения хоста от vCenter. Потом вы создаете три алерта, применяя к ним симптом, которые оповещают team A, team B или team C, в зависимости от того, какой хост отключился.

Далее если вы не хотите срабатывания алертов при переводе хостов в режим обслуживания, то вам нужно просто поменять симптом, не затрагивания алертов - вот чем удобна такая структура. Если же вам нужен обычный алерт, то вы его можете создать просто на базе условия (например, какая-то метрика перешла пороговое значение).

В обновлении Aria Operations 8.10 эти же практики применяются и к алертам, создаваемым через Troubleshooting Workbench или через вкладку метрик для объектов. К тому же, если вы создаете алерт, который использует ту же метрику, что и другой, то вам просто предложат обновить уже имеющееся определение, чтобы не дублировать сущности.

6. Улучшенное управление правами доступа пользователей

Теперь в Aria Operations появились сущности Scopes - это коллекции объектов, которые могут быть использованы как шаблоны при назначении ролей пользователям и группам. Раньше роли нужно было назначать для определенных объектов каждому пользователю или группе. Теперь при создании нового пользователя или группы, можно назначить им Scope, вместо того, чтобы выбирать для каждого пользователя облако/объект.

7. Поддержка хранилищ Raw Device Mapping

Теперь в Aria Operations 8.10 у администратора есть возможность получить детали конфигурации своих RDM-хранилищ, таких как режим совместимости, SCSI Bus Sharing и число RDM, привязанных к ВМ.

Новая версия продукта VMware Aria Operations 8.10 будет доступна осенью этого года. Официальная страница продукта находится тут.

Недавно мы писали об анонсированной на конференции VMware Explore 2022 платформе VMware Aria, которая пришла на смену семейству продуктов VMware vRealize для управления кросс-облачными виртуальными датацентрами, присоединив к себе решение Skyline.

Сегодня мы поговорим еще об одном продукте VMware Aria Operations for Networks 6.8, сменившем средство vRealize Network Insight 6.7, продвинув его версию на 0.1. Напомним, что vRNI - это платформа для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре.

Первое большое нововведение Aria Operations for Networks - это обновленный стартовый дэшборд, где собрана сводная информация об инфраструктуре сетевых взаимодействий виртуального датацентра.

Здесь есть информация о здоровье платформы и ее сборщиков, различные источники данных, такие как vCenter, NSX-T, AWS и физические серверы, алерты, инстайты в сетевом разрезе, а также выявленные аномалии.

Также тут представлены тепловые карты окружения, объединяющего онпремизные, облачные и гибридные облачные ресурсы. Среди инсайтов представлены рекомендации по оптимизации правил фаерволов, подсистемы безопасности и многого другого, что требует внимания администратора.

Ну и главное, что здесь визуально видно, что именно требует немедленного реагирования, чтобы обеспечить работоспособность, безопасность и производительность приложений:

Также появились улучшения функций Network Assurance and Verification, основанных на приложениях. Теперь они позволят повысить производительность за счет нахождения проблем в TCP-трафике с точки зрения задержек (latency), повторной передачи и отображения алертов на дэшборде. Также есть возможность сравнить поведение приложения на разном оборудовании инфраструктуры, чтобы определить есть ли ошибки конфигурации, такие как некорректный размер пакета или MTU.

Онпремизные инсталляции теперь поддерживают функции Guided Network Troubleshooting (ранее было доступно только для SaaS-версии), которые позволяют визуализовать взаимозависимости компонентов и пройти по шагам к источнику проблемы, что дает администратору ответ на вопрос, куда копать в поисках решения:

Также добавилось еще несколько новых возможностей:

• Улучшения Cisco ACI, включая возможность поиска путей в топологиях NSX-T и Cisco ACI, а также поддержка различных сценариев Endpoint Groups (EPG).
• VMware HCX API для автоматизации действий по миграции рабочих нагрузок в облако и между облаками.
• Улучшенная интеграция с VMware Cloud on AWS, что позволяет упростить развертывание продукта Aria Operations for Networks как аддона в облаке SDDC.
• Встроенные обучающие гайды для операций с трафиком, планирования инфраструктуры безопасности, обнаружения приложений, влияния найденных проблем на бизнес, сетевого здоровья компонентов и поисковых запросов.

Пробную версию продукта VMware Aria Operations for Networks 6.8 можно загрузить по этой ссылке.

На прошедшей конференции Explore 2022 компания VMware представляла большие корпоративные продукты, о которых мы пишем вот тут. Но был показан и еще один небольшой исследовательский проект - WebAssembly (Wasm) - открытый стандарт, определяющий бинарный стандарт исполняемых программ.

Во время демонстрации был показан эксперимент, который ставил своей целью собрать веб-сервер на базе самых дешевых микрокомпьютеров Raspberry Pi Zero W and Pi Zero 2 W. Эти маленькие low-end платы интегрируют в себе чипсеты BCM2835 (ARM 32-Bits / 1GHz) и BCM2710A1 (ARM 64-bits / Quad core 1GHz) и имеют на борту 512MB памяти SRAM. Системы эти очень бюджетные - стоят около $10, они применяются для прототипирования и некоторых прикладных задач.

Сервер построен на базе технологий Server Side Rendering (SSR) и client hydration, а весь стек включает в себя следующие компоненты:

• Preact
• Vite
• MDX

Технология Server-Side Rendering позволяет обработать клиентскую часть JS на стороне сервера и послать HTML-ответ в браузер. После загрузки специальный компонент берет на себя контроль над веб-страницей, чтобы обеспечить с ней интерактивное взаимодействие, которое называется hydration.

Вот что из этого получилось:

Развертывание веб-сервера производится в 4 простых шага:

1. Логинимся по SSH:

ssh pi@PI_ZERO_IP_ADDRESS

2. Скачиваем и распаковываем контент:

wget https://github.com/vmware-samples/webassembly-browser-apps/releases/download/pi-zero-ssr%401.0.0/build.tar.gz
tar xvf build.tar.gz

3. Запускаем веб-сервер:

# Pi Zero (32-bit):
./ssr-handler ./ssr.wasm ./dist
# Pi Zero 2 (64-bit):
./ssr-handler-64 ./ssr.wasm ./dist

4. Заходим на него:

http://PI_ZERO_IP_ADDRESS:8080

По итогам теста генерация страниц получилась достаточно производительной для 64-битной архитектуры:

Более подробно о проекте WebAssembly (Wasm) можно почитать в официальном репозитории на GitHub, а также в блоге VMware.

На прошедшей недавно конференции Explore 2022 компания VMware представила Project Newcastle - решение, использующее методику Post Quantum Cryptography (PQC) для создания фреймворка на базе политик, который позволяет организовать переход на современные технологии защиты для нового поколения приложений.

Вся индустрия шифрования на протяжении десятилетий использовала алгоритмы шифрования инфраструктуры открытых ключей RSA и ECDSA (Elliptic Curve Digital Signature Algorithm). С приходом квантовых вычислений их надежность в плане защиты от взлома с помощью квантовых компьютеров встала под угрозу.

Как многие знают, методики шифрования - это всегда компромисс между различными параметрами, такими как скорость обработки, размерность ключа, размер полезного сообщения и прочими. Чтобы перевести технологии шифрования на новый уровень, VMware представила методику Cryptographic agility - это механизм конфигурации на базе политик и платформа оркестрации для больших инфраструктур, где используются новые техники шифрования и обеспечивается обратная совместимость со старыми.

Project Newcastle, интегрированный с архитектурой Tanzu Service Mesh, предоставляет разработчикам средства, позволяющие перенастроить криптографию для приложений, чтобы она соответствовала политикам организации и отраслевым стандартам.

В партнерстве с компанией Entrust, VMware представила enterprise-grade решение, которое позволит обеспечить полную поддержку современных механизмов шифрования PQC с возможностью оркестрации операций жизненного цикла сертификатов на базе политик. Связка Entrust + Project Newcastle обеспечивает полную автоматизацию операций в этом ключе.

В рамках Explore 2022 компания VMware провела демонстрацию технологии Project Newcastle на базе облаков GCP и AWS, в которых располагаются кластеры Kubernetes:

Здесь представлена видимость криптографических политик между облаками, которые поддерживают провайдеров Post Quantum Cryptography при межоблачном взаимодействии.

При создании политики нужно указать область ее действия - для отдельных сервисов, кастомной группы или выбранных API. Ниже показан пример создания политики для всего приложения в варианте глобального пространства имен Global Namespace (GNS).

Далее определяется спецификация для создаваемой политики. Первый вариант - это кастомная политика криптографии на базе выбранных протоколов, используемых библиотек и прочего:

Для более простого варианта, который "просто работает", VMware рекомендует готовую политику, обеспечивающую комплаенс FIPS 140-3 и защиту от квантовых атак (quantum safety). Можно просто выбрать стандарт, который требуется в вашей организации:

Дальше нужно выбрать центр сертификации (certificate authority). VMware работает с Entrust, чтобы динамически развертывать сертификаты, соответствующие указанным требованиям. Служба Entrust PKI Service поддерживает сертификаты PQC:

Далее определяем, когда политика должна быть применена (прямо сейчас, сохранена как неактивная или внедрена в другой рабочий процесс):

После этого можно просмотреть данные о выбранной политике. Она будет обратно совместимой с уже существующими стандартами шифрования, такими как RSA, ECDSA и ECDHE:

Активация политики позволяет Project Newcastle перенастроить провайдеров шифрования, чтобы они соответствовали выбранным политикам. Это динамически включает возможность поддерживать PQC-коммуникацию между облаками. Ниже можно увидеть, что межоблачное соединение поддерживает стандарты NIST для аутентификации и обмена ключами:

Project Newcastle имеет встроенные средства для аттестации приложений, чтобы ограничить риски типа supply chain attacks. Для каждого приложения доступны не только сервисы аттестации, но и детальный отчет о статусе комплаенса для данного приложения в любой момент:

Более подробно о Project Newcastle можно узнать из следующих статей в блогах VMware:

• Computing Community Consortium: Identifying Research Challenges in Post Quantum Cryptography Migration and Cryptographic Agility
• Post-Quantum Cryptography and the Approaching Storm
• Post-Quantum Cryptography: Taking Stock of the Challenge Ahead
• A Deep Dive into VMware’s Crypto Agility Demo at VMworld 2021
• Kicking Off Your Organization’s Action Plan for Post-Quantum Cryptography Readiness
• Cryptographic Agility: Exploring Proxy Approaches
• NIST Algorithm Selection and National Security Memorandum

Компания NAKIVO выпустила обновление решения Backup & Replication v10.7, предназначенного для резервного копирования и репликации виртуальных машин в инфраструктуре VMware vSphere и Microsoft Hyper-V.

Давайте посмотрим, что нового в NAKIVO Backup & Replication v10.7:

• Backup to Azure Blob - теперь сами резервные копии и копии этих копий могут храниться в облачном блочном хранилище Azure Blob. Также для этого способа бэкапа поддерживаются функции immutability, то есть неизменяемость созданных копий.
• Backup to Backblaze B2 - теперь возможно резервное копирование в это облачное хранилище с обеспечением всех Enterprise-возможностей и функций immutability для защиты от ransomware.
• Microsoft Teams Backup - пользователям стала доступна защита данных инфраструктуры контента Microsoft Teams. Теперь можно сохранять и восстанавливать различные типы объектов, такие как каналы, посты и файлы для обеспечения непрерывности бизнеса.
• Wasabi Immutability - для этого типа хранилищ стали доступны функции immutability для защиты от ransomware на период, который определяется пользователем.
• Native Microsoft 365 Change Tracking - теперь для инфраструктуры Microsoft 365 работает технология быстрого создания инкрементальных бэкапов за счет интеграции с нативной технологией Microsoft для отслеживания изменяющихся блоков.
• Overview Dashboard - был добавлен дэшборд, на котором в реальном времени показываются основные параметры вашей бэкап-инфраструктуры, а также доступны функции для быстрого доступа к функциональности для защиты данных корпоративного датацентра.

Загрузить бесплатную пробную версию NAKIVO Backup & Replication v10.7 можно по этой ссылке.

Много лет назад мы писали о технологиях работы кэша write-through и write-back в ведущем на рынке виртуализации хранилищ решении StarWind Virtual SAN. С тех пор механика работы этих технологий была улучшена, но принципы остались теми же, как и большинство фундаментальных технологий. Сегодня мы поговорим о работе кэшей уровней L1 и L2, которые существенно улучшают быстродействие операций ввода-вывода.

При работе StarWind Virtual SAN с хранилищами используется кэш первого уровня (L1), располагающийся в оперативной памяти, а также кэш второго уровня (L2), размещенный на SSD-дисках, обеспечивающих высокое быстродействие системы.

StarWind использует традиционную оперативную память серверов (RAM) как буфер на чтение (write buffer) и L1-кэш, чтобы кэшировать операции записи, флэш-память SSD уже обслуживает кэш уровня L2. Оба кэша используют одни и те же алгоритмы - shared library, поэтому информация ниже применима, в основном, к кэшам обоих уровней. Об их отличиях мы также поговорим в статье отдельно.

При переполнении кэша нужно освободить его, используя какой-то алгоритм. StarWind применяет для этого алгоритм LRU - least recently used, то есть вытесняются данные (блоки), которые используются реже всего в последнее время.

В зависимости от степени исчерпания состояния кэша, его блоки могут находиться в одном из трех состояний: dirty, clean и empty. В самом начале блок помечается как empty - в нем нет данных, то есть блоки кэша не ассоциированы с блоками на диске. При работе кэша эти данные начинают заполняться. Блок помечается как dirty - если полезные данные были записаны в него, но еще не были записаны на диск (он не подтвердил запись данных). Блок помечается как clean, если данные из кэша были записаны на диск, либо блок кэша был записан в результате чтения в кэш блока с диска - то есть блок кэша и блок на диске содержат одинаковые данные.

Помните, что стандартный размер блока для кэша - 64 КБ.

Следующее полезное понятие - это прогрев кэша (cache warm-up). Эта концепция имплементируется на нижнем уровне в рамках сценария "in-memory" файловой системы LSFS (log-structured file system). Данные в кэш в этом случае попадают с диска, с учетом самых последних данных, записанных на диск.

Политики кэширования

Политика кэширования определяется вместе с другими параметрами кэша / устройств, когда они создаются. В StarWind Version 8 Release 5 режим работы кэша может быть изменен на лету для уже существующих устройств.

Write-back caching

Это режим, когда запись данных производится в кэш, но операция ввода-вывода (I/O) подтверждается, как запись на диск. Запись в основную память производится позже (при вытеснении или по истечению времени), группируя в одной операции несколько операций записи в соседние ячейки. Этот тип кэширования существенно ускоряет скорость записи данных на диск, однако имеет несколько меньшую надежность с точки зрения записи данных.

Если блок находится в статусе empty или clean, то запись в кэш происходит практически мгновенно, на уровне скорости записи данных в RAM или на SSD. А вот как работает кэш в разных обстоятельствах:

• Если операции записи не были сделаны в dirty-кэш на протяжении некоторого времени (по умолчанию 5 секунд), то данные записываются на диск. Блок переходит в состоянии clean, но данные в нем остаются.
• Если все доступные блоки кэша находятся в состоянии dirty, то данные, хранимые в самых старых блоках, форсированно скидываются на диск, а новые данные записываются в эти блоки. В этом случае производительность кэша несколько падает из-за требующихся операций записи на диск, и она сравнима со скоростью такой операции с диском.
• Если происходит сбой в работе сервера или памяти (или его выключают на обслуживание), то данные в кэше write-back, помеченные как dirty, немедленно сбрасываются на диск. Если размер кэша большой (гигабайты), то эта операция может занять значительное время. Его можно оценить так: Flushing time = cache size / RAM write.

Политика кэширования write-back ускоряет производительность в следующих случаях:

• Флуктуации нагрузки - кэш позволяет сгладить пики нагрузки за счет аккумуляции большого числа записей в кэше во время всплесков до момента снижения нагрузки.
• Постоянная перезапись тех же самых блоков - в этом случае они постоянно перезаписываются только в кэше, а на диск сбрасываются пачки блоков по мере необходимости.

Помните, что политика write-back предпочтительна для L1-кэша и в данный момент недоступна для L2-кэша, который всегда создается в режиме write-through.

Write-through caching

Это режим, когда запись производится непосредственно в основную память и дублируется в кэш. Такой тип кэширования не ускоряет запись данных на диск (но и не замедляет), но существенно увеличивает скорость чтения данных, которые можно взять из кэша. Этот тип кэша безопасен с точки зрения надежности данных и дает однозначный выигрыш в производительности.

При использовании этого типа кэширования не будет потери данных в случае неисправности сервера и памяти. Блоки памяти кэша в этом случае всегда помечены как clean.

Рекомендации по использованию кэша

L1 Cache

Он решает следующие проблемы:

• Запросы партнерского узла StarWind Virtual SAN могут приходить с небольшой задержкой и изменять порядок доступа к блокам, например, 1-2-3-4-5-6-7-8 изменится на 1-3-2-4-5-7-6-8. В этом случае L1- кэш сгладит поток последовательных запросов на запись с применением алгоритма round robin в дополнение к кэшированию. L1-кэш объединяет маленькие запросы записи в большие (write coalescing). Например, 16 запросов по 4k в кэш будут записаны на диск как единый блок 64к, что работает гораздо быстрее. Поэтому для такого кэша не нужно много памяти - от 128 МБ.
• L1 также компенсирует перезапись в те же секторы диска. Самая частая перезапись - это небольшие по размеру операции. Размер кэша должен зависеть от от частоты перезаписи данных и размера working data set. Чем чаще перезапись, теперь меньше вы можете делать кэш, но если больше размер working data set, то должен быть и больше кэш. В этом случае работает формула Tcached = Tdisk * (1 – (cache size) / (working set size)). В этом случае, если у вас кэш составляет 0.1 от data working set, процессинг данных будет составлять 0.9 от времени процессинга данных на диск. Если же cache size = working data set, то средний процессинг команд будет примерно равен времени процессинга команд в памяти.

StarWind L1 cache в режимах write-back и write-through может быть использован для:  

• Файловых устройств StarWind HA image file на базе HDD-хранилищ в конфигурации RAID 10.  
• Устройств StarWind LSFS на базе HDD в конфигурациях RAID 5, 6, 50, 60. Также посмотриите статью о требованиях устройств LSFS.

Также помните, что в большинстве случаев для дисковых массивов all-flash кэш уровня L1 вам не потребуется.

В идеале размер кэша L1 должен быть равен размеру working data set. Также размер кэша L1 влияет на время, которое вам потребуется, чтобы выключить сервер (нужно сбросить грязные блоки на диск). Также помните, что лучше не делать L1 кэш в режиме WB, чтобы не создавать ситуацию, когда большой объем данных может быть утерян.

При использовании кэша L1 в режиме write-back обязательно используйте UPS для серверов, чтобы не потерять часть данных. Время работы UPS должно позволяет сбросить содержимое грязного кэша на диск.

L2 Cache (Flash Cache)

Для обслуживания кэша L2 создается обычное устройство ImageFile device. У этого устройства нет таргета, и оно соединено с системой точно так же, как и устройство с данными (ImageFile or LSFS).

Система с кэшем L2 должна иметь больше оперативной памяти RAM для обеспечения накладных расходов. Формула тут такая: 6.5 ГБ RAM на 1 ТБ кэша L2, чтобы хранить метаданные. Более подробно о кэше L2 можно почитать в базе знаний StarWind.

StarWind L2 cache может быть использован для следующих сценариев:

• HA-устройства StarWind image file на базе HDD в конфигурации RAID 10.
• Устройства StarWind LSFS на базе HDD в конфигурации RAID 5, 6, 50, 60.
• HA-устройства StarWind image file на all-flash хранилищах в некоторых сценариях. Более подробно об этих сценариях можно почитать в базе знаний StarWind.

В большинстве случаев, когда у вас есть L1 кэш, кэш уровня L2 вам не потребуется. Размер L2 кэша должен быть равен среднему объему уникальных данных, запрашиваемых с хранилища на регулярной основе (определяется экспериментально).

На конференции VMware Explore 2022 было сделано очень много интересных анонсов. В частности, мы писали о vSphere 8, vSAN 8, Project Northstar и Project Watch, а сегодня мы расскажем еще об одной технологии - Project Trinidad.

Эта платформа от VMware будет реализовывать API и аналитические инструменты для выявления подозрительных активностей, которые будут обнаруживаться в трафике, которым обмениваются современные приложения. С помощью Project Trinidad можно будет использовать API для East-West трафика между приложениями на базе микросервисной архитектуры, чтобы обнаруживать паттерны нормального взаимодействия и выявлять подозрительные коммуникации, обнаруживать которые человек не способен. В качестве примера можно привести уязвимость Heartbleed, трафик которой для администраторов выглядел вполне нормальным.

Ключевые особенности Project Trinidad:

• Обнаружение Zero-day атак в современных приложениях
• Моделирование нормального поведения приложений, обнаружение и предсказывание аномального поведения
• Помещение на карантин подозрительных коммуникаций
• Не требуется развертывание дополнительных специальных средств

Сейчас атаки на корпоративные инфраструктуры стали более комплексными, в том числе ввиду усложнения самих онпремизных и облачных сред. Администраторы используют сотни решений, многие из которых построены на базе стандартных компонентов, используемых в программном обеспечении по всему миру. Уязвимость Log4j показала, что зачастую стандартные системы защиты просто не работают при анализе и обнаружении вторжений.

Project Trinidad сочетает в себе как средства обеспечения безопасности, так и средства для observability - то есть наблюдения за трафиком за пределами мониторинга человеком. Инсайты по безопасности, выявленные Project Trinidad, можно быстро использовать, чтобы незамедлительно закрыть дыры в инфраструктуре.

Продукт будет работать как SaaS-сервис и не требовать вмешательства со стороны администратора для поддержки решения. Также будет доступна и онпремизная инсталляция, чтобы дать клиентам максимальную гибкость. Решение будет съедать менее 5% ресурсов, но зато даст администраторам любых компаний средства обеспечения безопасности самого высокого уровня.

Средства federated machine learning (FML) позволяет использовать алгоритмы машинного обучения, наученные на большом количестве данных об уязвимостях, что позволяет начать использовать продукт сразу, без необходимости собственного обучения на своей инфраструктуре.

На данный момент платформа Project Trinidad находится в стадии внутренней разработки и технологического превью, о дате ее доступности пока не сообщается. Более подробно о технологии federated machine learning также можно почитать вот тут.

На конференции VMware Explore 2022 компания VMware представила много новых интересных проектов, продуктов и технологий. Недавно мы писали о vSphere 8, vSAN 8 и Project Northstar, а сегодня поговорим еще об одной интересной инициативе - Project Watch.

В прошлом году компания VMware анонсировала технологию Elastic Application Security Edge (EASE), которая обеспечивает надежное и безопасное соединение между облаками на уровне датацентров или облачных edge-компонентов для приложений, которые постоянно меняются и нуждаются в мобильности. Для того, чтобы защитить текущие инвестиции компаний в оборудование, которое не может обеспечить все потребности меняющейся структуры облачных приложений, и был придуман Project Watch.

Эта технология позволит исполнять операции и надежно поддерживать мультиоблачные соединения поверх существующей аппаратной архитектуры и инфраструктуры безопасности. Это будет включать в себя следующие аспекты:

• Автоматическое поддержание зашифрованных межоблачных соединений Clouds (AWS, Azure, and GCP), виртуальные домены Cloud Zones (VPC и VNET), а также операции в сфере обеспечения безопасности для снижения вероятности человеческой ошибки.
• Непрерывный анализ рисков и комплаенса в сфере безопасности с возможностью получить набор средств для ограничения рисков и следования корпоративным политикам.
• Интеграция рабочих процессов SecOps, CloudOps и бизнес-подразделений для более эффективной коммуникации между командами.

То есть, Project Watch - это расширение существующей архитектуры доступности и безопасности приложений:

Когда мы говорим о доступности, то есть стандартные термины в SLA, как, например, надежность 5 девяток (99.999%), а вот в плане безопасности таких общепринятых метрик нет.

Project Watch как раз будет вводить стандарт в области оценки рисков, который будет говорить о численных метриках взаимодействий. Например, в соответствии с корпоративной политикой типы взаимодействий user-to-app и app-to-app могут осуществляться только, если их risk score составляет менее 73.

При этом будут приниматься во внимание и небинарные решения, где администратор выбирает не только правила Permit/Deny. С помощью Project Watch можно будет поддерживать высокий уровень доступных коммуникаций с постепенным ограничением рисков и гибким регулированием правил.

Поддерживая и традиционную структуру политик Permit/Deny, Project Watch позволит постоянно анализировать риски источника, назначения и структуру коммуникации при проведении транзакций, чтобы обеспечить следующее:

• Решения по предоставлению доступа становятся адаптивными и пересматриваемыми в реальном времени для баланса факторов доверия, риска, чувствительности данных и критичности для бизнеса.
• Теперь можно будет дать либо "добро" на коммуникацию, либо устранить риск, чтобы иметь такую возможность, и дать зеленый свет транзакциям, для которых ранее стояло жесткое правило Deny.

Этот подход требует вовлечения и других вендоров экосистемы безопасности в этот процесс. Чтобы все действовали в рамках одного набора определений, нужно договориться о методике оценки risk score, а также способах мониторинга, оценки и ограничения рисков.

Таким образом, VMware работает, что стандартизировать индустрию безопасности в рамках политик и оценки рисков, для чего будет доступен open risk framework, который реализует следующие вещи:

• Indicators of Risk (IoR) - это параметры, которые будут доступны стороннему ПО. Там будут утилиты для безопасности, метки рабочих нагрузок, контекст окружения, а также классификация операций и данных при коммуникации в рамках сессии источника и назначения.
• IoR могут быть организованы в объекты buckets, такие как индикаторы типа Strategic, Operational, Security и Compliance, которые можно использовать для численного измерения рисков между источником и назначением.
• Далее риски просчитываются непрерывно, как часть транзакции, а также появляется и оценка потенциальных рисков для источника, назначения и самой коммуникации.
• Далее можно делать базовые уровни для рисков (baselining) для разных приложений и окружений, используя стандартные профили рисков, а также гибко ограничивать риски путем регулировки пороговых значений (thresholds).

Доступность технологического превью платформы Project Watch ожидается в ближайшие несколько месяцев.

На конференции VMware Explore 2022 компания VMware объявила о выпуске решения для организации отказоустойчивых кластеров виртуальных хранилищ VMware vSAN 8. Напомним, что прошлая мажорная версия VMware vSAN 7 была выпущена в марте 2020 года. Вчера мы писали о новых возможностях VMware vSphere 8, а сегодня поговорим о решении vSAN 8, которое очень тесно интегрировано с vSphere.

Итак, что нового появилось в VMware vSAN 8.0:

Новая архитектура vSAN Express Storage Architecture

В vSAN 8 появилась новая архитектура гиперконвергентной инфраструктуры vSAN Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

С помощью флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ со стандартной vSAN Original Storage Architecture (OSA), которая также продолжит поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

Ключевыми структурными особенностями vSAN 8 ESA является переработанная и запатенованная файловая система (log-structured file system, LFS), новый оптимизированный для записи менеджер объектов (log-structured object manager), а также новый формат дисковых объектов.

Эти технологии позволяют добиться такого уровня производительности, где практически не происходит потерь на поддержание слоя виртуализации.

Новые возможности ESA дают преимущества в следующих аспектах:

1. Performance without tradeoff

Здесь есть два основных момента, существенно увеличивающих производительность:

• Изменение структуры хранения и обработки данных для алгоритмов RAID 5/6 erasure coding. Теперь производительность RAID 5/6 близка к таковой на базе RAID-1. За счет LFS и нового формата дисковых объектов обеспечивается высокая интеграция данных и устойчивость к отказам при сохранении высокой скорости канала чтения-записи.
• Intelligent I/O traffic management для сетевого трафика vSAN - теперь скорость процессинга трафика ввода-вывода близка к нативной для используемых устройств. Это достигается, в том числе, за счет адаптивной приоритизации трафика и его отсылки в моменты наименьшей загрузки канала.

2. Supreme resource and space efficiency

Адаптивный алгоритм обработки данных на RAID-5, который проверяет количество хостов в кластере и выбирает оптимальный способ размещения данных (работает, начиная с трех хостов). vSAN ESA также имеет возможности обнаружения изменений хостов, что влечет за собой ревизию структур данных RAID-5 и изменения политик размещения данных. В этом случае RAID-5 использует меньше сырой емкости хранилищ при сохранении надежности и управляемости.

Кликните на картинку, чтобы открыть анимацию:

Также были полностью переработаны механизмы сжатия данных, чтобы оптимизировать загрузку сети и нагрузку на CPU. Компрессия включена по умолчанию, и ее настройки можно изменять на уровне отдельных виртуальных машин с помощью политик хранилищ, вместо изменения конфигурации на уровне кластера.

Нажмите на картинку для открытия анимации:

Новый метод сжатия дает до 4x улучшение для каждого блока размером 4KB, если сравнивать с Original Storage Architecture. Также нагрузка на CPU существенно меньше у ESA, чем у OSA.

Шифрование данных также происходит теперь на верхних слоях ядра vSAN. Поскольку шифрование проводится для уже сжатых данных, то процесс шифрования происходит только однажды, что означает, что потоки данных между хостами также зашифрованы. Это позволяет избавиться от лишних шагов decrypt/encrypt и дает меньше нагрузки на CPU и сеть, освобождая ресурсы на поддержание работы виртуальных машин.

3. Intuitive, agile operations

Здесь два основных момента:

• Storage pool construct - vSAN 8 ESA, помимо концепции дисковых групп, дискретного кэширования и ярусов емкостей (capacity tiers), дает пользователям возможность объединить устройства в пул (storage pool), в котором все устройства пула хоста могут давать емкость в общую емкость инфраструктуры vSAN. Это упрощает операции по обслуживанию дисков и управлению доступностью данных (а также снижает затраты).
• Упрощенное развертывание и оперирование ресурсами хранилищ - теперь появились автоматические проверки, которые позволяют понять, что архитектура ESA запущена на поддерживаемом оборудовании. Это уменьшит количество проблемных инсталляций.

4. Ready-for-anything resilience

Этот пункт включает в себя масштабируемые и высокопроизводительные снапшоты, которые теперь делаются быстро и эффективно. Теперь снапшоты не так драматически влияют на производительность виртуальных машин, а время консолидации снапшотов уменьшилось очень значительно. Возможность native snapshot будет доступна не только в vSphere, но и для сторонних решений, использующий фреймворк VADP для резервного копирования ВМ.

Стандартная архитектура vSAN Original Storage Architecture

Классический vSAN 8 увеличил логический лимит емкости буффера почти в три раза - с 600 ГБ до 1.6 ТБ. Это позволит получит преимущества более плотного размещения виртуальных машин при сохранении требуемого уровня производительности. Рабочие нагрузки теперь могут поддерживать режим максимальной производительности в течение больших периодов времени.

Обе архитектуры vSAN - ESA и OSA

vSAN Proactive insights capability - пользователи vSAN 8 теперь получили более высокий уровень совместимости за счет функционала proactive insights, который оповещает обо всех потенциальных проблемах совместимости программного обеспечения и оборудования, даже если оно не участвует в программе Customer Experience Improvement Program. Эти улучшения доступны для обеих архитектур.

Итого прогресс технологии VMware vSAN за 10 лет можно представить вот так:

Доступность для скачивания продуктов VMware Cloud Foundation+, VMware vSphere 8, VMware vSAN 8 и VMware Edge Compute Stack 2 ожидается до 28 октября 2022 года.

Также рекомендуем посмотреть техническое видео о нововведениях vSAN:

В рамках событий первого дня проходящей сейчас конференции VMware Explore 2022 была анонсировала платформа виртуализации VMware vSphere 8. Это событие очень ждали многие администраторы и менеджеры датацентров, так как с момента релиза прошлой мажорной версии платформы VMware vSphere 7 прошло уже два с половиной года. Давайте посмотрим, что нового в VMware vSphere 8...

В своем финансовом отчете за второй квартал этого года компания Intel неожиданно объявила о том, что сворачивает (winding down) разработку технологии оперативной памяти Intel Optane. В свете падения квартальной выручки аж на 22% год к году, Intel просто не может поддерживать все перспективные технологии, требующие больших инвестиций в R&D.

Кстати, AMD во втором квартале этого года почти удвоила выручку (сказался еще эффект включения выручки приобретенной компании Xilinx):

Это оказалось, довольно-таки, неожиданной новостью для компании VMware, которая ориентировалась на поддержку этого типа памяти в своих продуктах, например, планируемом к выпуску решении Project Capitola. В данном продукте будет использоваться так называемая Software-Defined Memory, определяемая в облаке (неважно - публичном или онпремизном) на уровне кластеров VMware vSphere под управлением vCenter.

В Project Capitola вся доступная память серверов виртуализации в кластере агрегируется в единый пул памяти архитектуры non-uniform memory architecture (NUMA) и разбивается на ярусы (tiers), в зависимости от характеристик производительности, которые определяются категорией железа (price /performance points), предоставляющей ресурсы RAM. Все это позволяет динамически выделять память виртуальным машинам в рамках политик, созданных для соответствующих ярусов.

На рынке серверной виртуализации уже довольно давно развивается экосистема оперативной памяти различных уровней - стандартная DRAM, технология SCM (Optane и Z-SSD), модули памяти CXL, память PMEM, а также NVMe. Однако в разработке технологий по виртуализации оперативной памяти компания VMware ориентировалась, в первую очередь, именно на Intel Optane.

Память Intel Optane DC persistent memory (DCPMM она же PMEM) не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте. В конце прошлого года мы писали о производительности этого типа памяти.

Теперь пользователи аппаратных устройств на базе Intel Optane продолжат получать стандартную поддержку Intel до окончания периода End-of-life, а также гарантию, действительную в течение 5 лет. Это касается следующих продуктовых линеек:

• PMem 100 series ("Apache Pass")
• PMem 200 series ("Barlow Pass")
• DC P4800X SSD ("Cold Stream")
• DC P5800X ("Alder Stream")

Также сообщается, что Intel продолжит развивать технологию PMem 300 series ("Crow Pass") для четвертого поколения процессоров Intel Xeon Scalable ("Sapphire Rapids").

VMware планирует продолжать поддержку памяти Intel Optane PMem в платформах vSphere 7.x и vSAN, а также будущих релизах этих продуктов. На данный момент память Optane поддерживается в трех режимах:

• Обычная оперативная память (Memory mode)
• App-Direct mode через механизм vPMem

• Как персистентное хранилище через объекты vPMemDisk

VMware также добавила расширенные механизмы по поддержке vMMR в vSphere 7 Update 3 и добавила различные интеграции с механизмом DRS в следующей версии платформы. О технологии vMMR можно прочитать подробнее тут.

Также VMware поддерживает все предыдущие поколения технологии Intel Optane PMem, о чем можно почитать в KB 67645. Ну и VMware будет поддерживать будущее поколение Optane PMem 300, которое Intel, вроде как, не планирует сворачивать.

Ну а что касается Project Capitola, то VMware не будет поддерживать Intel Optane в этом решении, а переключится на технологии памяти стандарта CXL, который, как ожидается, получит большое распространение в отрасли. Посмотрим еще, что на эту тему еще расскажут на предстоящей конференции VMware Explore 2022.

В августе этого года компания VMware обновила свои решения для проактивного получения рекомендаций по технической поддержке продуктов линейки VMware vSphere - Skyline Advisor Pro и Skyline Collector 3.2. Напомним, что с помощью этих продуктов пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут просматривать информацию об инфраструктуре клиента и предоставлять информацию о текущем состоянии инфраструктуры, а также выдавать полезные рекомендации по ее улучшению.

Если у вы применяете автоматический апгрейд со Skyline версии 3.1, то имейте в виду, что есть некоторые проблемы с таким типом обновления, описанные в KB 89230. В ручном режиме апгрейд проходит нормально.

В Skyline Collector версии 3.2 исправлена проблема с решением NSX-T. При обновлении NSX-T с версии 3.x на 4.0.x компонент Collector версии 3.1 падал. Подробнее вы можете почитать об этом в KB89303. В версии Collector 3.2 эта проблема решена.

Итак, что нового появилось в Skyline Advisor Pro и Skyline Collector 3.2:

1. Улучшения дэшбордов

Теперь можно кликнуть на один из элементов Active Findings, Findings Type, Findings Category, Support Requests и Active Log Assists для перехода в детальное представление каждой из этих секций прямо из главного дэшборда.

Также фильтры теперь интегрированы напрямую в дэшборд (gif-картинка откроется в новом окне по клику):

2. Самостоятельные отчеты для пользователей VMware Success 360 и Premier Services

Если вы пользователь VMware Success 360 или Premier Services, то у вас теперь есть доступ к разделу самообслуживания Proactive Insights Reports. Эти отчеты заменят Operational Summary Reports (OSR), которые есть у клиентов Premier Services (новые OSR больше не будут создаваться и придут в статус End of Life 17 октября этого года).

Gif-картинка откроется в новом окне по клику:

3. Ускоренная доставка email-нотификаций

Если пользователь подписался на email-оповещения для критических объектов Findings, то теперь они будут получены в течение 24 часов вместо 48 в прошлых версиях.

Gif-картинка откроется в новом окне по клику:

4. Новые объекты Proactive Findings 

В новой версии Skyline было добавлено несколько объектов Findings, включая новые уязвимости и наиболее часто возникающие и просматриваемые пользователями проблемы. Подробнее о добавленных Findings можно почитать вот тут.

Gif-картинка откроется в новом окне по клику:

Более подробно о нововведениях Skyline Advisor Pro и Skyline Collector 3.2 можно почитать в материалах сообщества по продукту Skyline.

На сайте проекта VMware Labs вышло очередное обновление полезной многим адимнистраторам VMware vSphere утилиты - Control My Update 2.1. Напомним, что это средство позволяет контролировать и управлять всеми обновлениями, предоставляемыми через Windows Update. В прошлый раз мы писали об этой утилите вот тут.

С помощью Control My Update можно создавать полностью поддерживаемые со стороны Windows Update конфигурации и использовать саму утилиту для их установки и мониторинга. CMU состоит из двух отдельных компонентов:

• Custom Profile Generator - это графическая PowerShell-утилита, которая дает GUI для конфигурации профилей Windows Update с наиболее актуальными поддерживаемыми настройками (20H2 и более поздние). Также можно создавать Delivery Optimization Profiles и конфигурации самой утилиты Control My Update.
• Control My Update - это надстройка над Windows Update для накатывания патчей и формирования отчетов. Вы можете выбрать источник обновлений - WSUS или Microsoft Update, определить окна обслуживания для установок обновлений и загрузить все необходимые апдейты перед установкой (что уменьшает время для нескольких систем). После этого можно накатить обновления и emergency-патчи, создавать кастомные нотификации и исключать отдельные KB из потока установки обновлений.

Давайте посмотрим, что нового появилось в Control My Update 2.1:

• Новый интерфейс Profile Generator в части настроек компонента CMU.
• Параметр Retry count для обработки возникающих ошибок (полезно при скачивании и установки апдейтов).
• Пофикшена ошибка с ситуацией, когда перезагрузка не происходила, если нет ожидающих обновлений.
• Новый механизм нотификаций в пассивных pop-up сообщениях.
• Улучшенный механизм обнаружения обновлений и отчетности.
• Добавлен тест службы Windows Update and Delivery Optimization.
• Добавлена возможность функции принудительной перезагрузки для не-Windows систем.
• Появилась опция автоматической перезагрузки для Windows-систем.
• Добавлена возможность поддержки старых механизмов configuration service provider (обнаружение 32/64-битных систем).
• Исправлена ошибка функции логирования (в логах не было даты и времени после определенного момента).

Загрузить Control My Update 2.1 можно по этой ссылке (там же в комбобоксе загрузки можно скачать и документацию).

Многие крупные компании используют решение VMware vRealize Operations для управления и мониторинга виртуальной инфраструктуры на платформе VMware vSphere. Иногда виртуальных машин становится так много (учитывая, что их бесконтрольно создают разработчики и тестировщики), что лицензии на vROPs, которые учитываются по виртуальным машинам, быстро заканчиваются.

Кроме того, с введением функций vSphere Cluster Services и Workload Management, а также vSAN File Share появились системные виртуальные машины, которые по умолчанию не исключаются из мониторинга в vRealize Operations Manager.

Чтобы исключить ненужные машины из мониторинга и потребления лицензий, можно использовать группы лицензий (License Groups). Итак, вам нужно создать группу виртуальных машин, члены которой будут исключены из мониторинга и не будут потреблять лицензии.

• Логинимся в интерфейс vRealize Operations Manager как администратор.
• Идем в Home > Administration > Licensing > License Groups.
• Нажимаем на виртикальное многоточие опций на нужной группе лицензий и выбираем пункт Edit (если у вас уже есть группа), либо можно создать новую группу в пункте ADD.
• Выбираем license key и нажимаем Next.
• В нижней части экрана в разделе Object to always exclude добавляем виртуальные машины, которые мы не хотим, чтобы потребляли лицензии в этой группе.
• Нажимаем Next и Finish.
• Возвращаемся на вкладку License Keys, нажимаем на многоточие и выбираем пункт Refresh License Usage.

Информацию о создании и редактировании групп лицензий вы можете найти тут. Помните, что хосты, на которых нет ВМ, потребляющих лицензии, но добавленные в vROPs - все равно будут потреблять лицензии.

Больше подробностей о работе с группами лицензий в vRealize Operations вы можете узнать из этой статьи.

Недавно мы писали о том, что VMware Application Catalog стал частью VMware Marketplace. Напомним, что Application Catalog, доступный через VMware Cloud Services Platform - это ресурс для производственных сценариев на базе контейнерных сред, который ранее назывался Tanzu Application Catalog.

Там находятся сертифицированные VMware Open Source образы, которые постоянно тестируются и верифицируются, чтобы пользователи могли их безопасно внедрять в свои производственные окружения.

Давайте посмотрим, какие нововведения появились в VMware Application Catalog в августе этого года:

• Поддержка архитектуры OpenShift - теперь все образы тестируются и верифицируются для Helm-пакетов в каталоге Red Hat OpenShift в дополнение к существующей поддержке Tanzu Kubernetes Grid, Amazon Elastic Kubernetes Service (EKS) и Google Kubernetes Engine (GKE). Для них также обеспечивается соответствующий уровень безопасности и совместимости.
• Расширенная поддержка образов операционных систем - теперь поддержка long-term support (LTS) предоставляется для ОС Ubuntu 20 LTS, Debian 11 и Photon OS 4.0.
• Уменьшенное время доставки образов - теперь когда пользователи запрашивают новые приложения, VMware Application Catalog использует более эффективный и более короткий по времени процесс.
• Подписывание и верификация образов через Sigstore Cosign - теперь все объекты VMware Application Catalog (образы контейнеров, бандлы метаданных, Helm-пакеты и бандлы их метаданных) подписываются с помощью решения Sigstore Cosign, что позволяет убедиться в их аутентичности и неизменности.
• Новые приложения в каталоге - теперь добавлены Kubeapps, Matomo, Percona MySQL, Loki, Promtail, Blackbox Exporter, Pinniped, и Schema Registry. Добавление Loki в каталог означает и полную поддержку стека Grafana.

Полный список поддерживаемых приложений VMware Application Catalog можно посмотреть здесь. Сам каталог доступен по этой ссылке.

На сайте проекта VMware Labs доступно очередное обновление полезной для администраторов утилиты - vRealize Build Tools 2.26.2. Напомним, что это средство позволяет разработчикам и администраторам, работая совместно, реализовывать новые сценарии и рабочие процессы vRealize Automation (vRA) и vRealize Orchestrator (vRO), используя стандартные практики DevOps. Напомним, что о прошлой версии этого решения мы писали вот тут.

Посмотрим, какие улучшения были сделаны в vRealize Build Tools 2.26.2:

• Добавлена возможность не использовать versions.json для объектов blueprints посредством свойства vrang.bp.ignore.versions
• Добавлена поддержка контент-паков vRealize Log Insight 8.8
• Несколько типов входных параметров для рабочего процесса установки (Array/string, number, boolean)
• Модули зависимостей бандлов для проекта PowerShell Polyglot
• Переработано руководство в основной папке
• @param теперь поддерживает различные свойства
• Улучшены сообщения об ошибках
• Улучшена обработка файла content.yaml при пуше на сервер
• Улучшена обработка дисков First Class Disks (FCD)
• Исполняемый файл смигрирован на PowerShell 6
• Множество исправлений найденных ранее ошибок

Скачать vRealize Build Tools 2.26.2 можно по этой ссылке.